能耗调试新特性

发表于

Session 228 《What’s new in energy debugging》的内容以及一些理解。

概要

WWDC Session 228《What’s new in energy debugging》的内容以及一些理解。
该Session主要从三方面来对能耗以及能耗调试进行讲解：

  1. 回顾电池寿命概念(Review general battery life concepts)
  2. 回顾调试能耗的工具(Review tools for energy debugging)
  3. 调试能耗的新特性(New features for energy debugging)

回顾电池寿命概念

能量(Energy)


在程序运行时，能量的消耗有高峰也有低谷,
不同运行模式下，功耗是不一样的:

  • 程序处于活跃状态时，能量消耗可能会达到最高点
  • 程序在运行但空闲时，能量消耗会降低
  • 程序在挂起时，会有基本的能量消耗

开销(Overhead)


当程序按照设计去做它该做的工作时，它会要求系统提供它工作所需要的硬件资源。虽然程序并没有直接控制硬件资源，但是它通过它所做的工作来影响硬件资源的使用，这些硬件资源的使用被称作开销(Overhead) .

活动能源(Active energy)


当程序开始利用硬件资源(开销)来做工作时，此时一些子系统消耗的能源就叫做活动能源(Active energy) .

子系统


App耗电的”罪魁祸首”:

  1. 处理(Processing)
  • 是工作的组成部分
  • 处理消耗取决于工作量
    总结：App操作越多 = 越多的功耗
  1. 网络(Networking)
  • 通过蜂窝(Cellular)、Wi-Fi、蓝牙(Bluetooth)来与网络交互都会消耗能量
  • 网络消耗取决于流量
    总结：网络请求越多 = 越多的功耗
  1. 定位(Location)
  • 通过GPS、Wi-Fi、蜂窝(Cellular)来定位会消耗能源
  • 定位消耗依赖于定位的精度和频率
    总结：定位时间越长 = 越多的功耗
  1. 图形(Graphics)
  • 动画和UI布局会通过CPU或GPU来消耗资源
  • 图形消耗依赖于动画或UI的复杂度
    总结：需要渲染的越多 = 越多的功耗

我们通过对四个子系统的分析可以得出：

1
App需要做的工作越多，那么功耗就越多。

但我们不必让App少做工作，App越少做工作，表明App功能越少。我们需要思考的是如何优化App的工作以及使这些工作尽可能的节能。

节能主要思路

程序在前台

程序在前台运行时,我们降低能耗的主要思路是只做必要的工作以及降低UI复杂度.

只做必要的工作

我们构建了一个媒体应用，这个应用主要目的是以常规的节奏为用户提供新内容

如果我们使用Timer来按照常规的节奏来进行内容刷新，这种方式将不是节能的，下图是随时间变化的功率图

我们可以看到，在每次Timer启动的时候，我们都会有功能的消耗，但是这并不是主要的，更主要的是，每次Timer启动，都意味着我们可能去启动网络、图形以及处理等子系统来完成显示，这样随着程序的运行，我们会有一个持续的能量消耗。
我们采用根据用户交互(例如下拉刷新)或者服务器通知来触发新内容的获取以及展示。这里的功率图如下，从图中可以看出，功耗已经被降低了很多.

降低UI复杂度

我们构建了一个视频播放器，并且有一些UI控件来控制视频的播放(例如：音量、播放进度)，但是如果该控件一直存在的话，是十分消耗资源的，原因是：在许多设备上，当屏幕上没有用户界面时，会有一个显示的优化，这个优化可以让视频播放十分节能。

所以我们可以改变一下解决方案：我们可以根据用户在一定时间内没有交互，那么我们就让控制控件进行隐藏，从而使用到显示优化来进行能源的较低消耗。

程序进入后台

程序进入后台时,我们降低能耗的主要思路是尽可能的合并任务,对已完成的任务应及时结束.

合并任务

我们经常会上传分析日志并使用这些分析来防止应用崩溃。所以我们一般的做法是在每次应用进入后台时都会发送分析日志，这种操作的功率消耗如下图：

我们可以看出，在每次进入后台时，都会启动网络请求来发送分析日志，随着时间的推移，这种功耗是非常大的。

我们正确的做法是分批发送分析日志。系统提供的很多API都支持合并原则，其中NSURLSession也支持合并原则：使用自主属性的NSURLSeesion和后台session会自动优化这种操作。下图是使用合并原则之后的功率消耗：

快速结束任务

系统提供了很多API允许程序在后台运行：UI后台任务、UIKit、VoIP和PushKit。同时这些API为开发人员提供了指示不再需要后台运行的方法。如果你在后台模式下使用了这些API，你应该调用完成回调告诉系统已经结束任务了。

我们可以看到，在任务开始后的一段时间，任务执行完成，此时任务会进入空闲阶段，会继续进行能源的消耗，这就造成了能源的浪费。
正确的做法是，只要它们完成，就调用完成回调通知系统任务结束。这种做法的能耗图如下：

回顾调试能耗的工具

能量计(Energy Gauges)


这里不赘述了,之前就有的功能.

调试能耗的新特性

Xcode Energy Logs

对于调试已经存在于App Store或者TestFlight中的App，用户使用的场景与测试场景完全不一样，用户可能在Wi-Fi情况很差的情况下使用，而我们测试时是在Wi-Fi情况很好的情况下，所以对于这种情况,我们需要下面两个工具:
Xcode Energy Logs AND Xcode Energy Organizer
Xcode Energy Logs是报告设备能源问题的新方法:

  • 在高CPU能耗事件进行报告
  • 加权调用图可以指出代码中的能耗热点
  • 数据来自TestFlight和App Store，即来自于用户真实使用场景中

触发生成的事件有两个：

  1. 前台超过3分钟超过80%的CPU使用。
  2. 后台超过1分钟超过80%的CPU使用，这种情况应用程序会被杀死。
    这两个触发条件意味着会造成1%的电池电量的下降。1%的电池电量意味着在iPhone 6s上:

Xcode Energy Logs组成:

  1. 触发报告的能源状况(例如：应用在3分钟内耗费8%的资源)
  2. 设备类型和应用程序构建版本号
  3. 能源热点中的加权调用图

加权调用图:

  1. 假设代码中有一个main函数和许多函数构成(method1、method2、method3、method4)
  2. 当程序运行到检测到高CPU能量时间时，会以每秒1次的周期进行采样:
  3. 每个采样数据中都是当前时间点的活跃函数:
  4. 将获得到的采样数据进行组合，就能得到一副加权调用图:

日志获取流程

  1. 设备创建日志。
  2. beta测试人员或者用户将日志上传Apple。
  3. App对成千上万的日志进行汇总分类整理，创建一个列表。
  4. 开发者使用Xcode Energy Organizer来下载查看列表

Xcode Energy Organizer

入口: Xcode->Window->Organizer->Energy

总结

考虑能源的使用，并在设计、开发和测试中将能源视为最重要的资源。
利用Energy Gauges和Instruments来调试App
多使用Xcode Energy Organizer新特性来发现能耗问题